ci: build production app + worker Docker images from main#392
Merged
Conversation
Adds a non-blocking "Docker image build" workflow that runs the exact
npm ci + next build the Fly.io / Cloud Run deploy runs, on a GitHub runner
with enough memory for the build's 8 GiB heap (local Docker Desktop OOMs on
it). Fulfils the deploy contract in docs/deployment-architecture.md ("Images
are built from main"): every main/release push now proves the tree produces a
deployable image before a real deploy. Nothing is pushed to a registry — the
build just succeeds or fails. Gated to main/release/dispatch/schedule to bound
CI cost; run on a branch on demand via "Run workflow".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Adds a paths-scoped pull_request trigger (Dockerfiles, deps, engine/build guards, the workflow itself) so containerization is validated before merge when it can actually break, without rebuilding on every src-only PR (verify already runs next build for those). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
BigSimmo
enabled auto-merge
July 8, 2026 08:48
Owner
Author
|
✅ Both images build green on CI (run 28929799637):
This confirms |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a non-blocking Docker image build workflow (
.github/workflows/docker-image.yml) that builds the production app (Dockerfile) and worker (Dockerfile.worker) images on GitHub runners.This fulfils the deploy contract in docs/deployment-architecture.md — "Images are built from
main… CI job to be added" — and closes the gap surfaced while validating deployability of the demo-leak fix (#373/#378): the image build runs the exactnpm ci+next builda Fly.io / Cloud Run deploy runs, but thenext buildstep allocates an 8 GiB heap and OOMs local Docker Desktop. GitHub runners (~16 GiB) have the headroom, so this validates image buildability where it can actually complete.Design
verifycheck. It does not gate merges.main/release/**,workflow_dispatch, and the weekly schedule — not on every PR (mirrors howrelease-browser-matrix/ deployment-boot-smoke are gated). Trigger on a branch on demand via "Run workflow".Verification
yaml.safe_load)Dockerfile+Dockerfile.workerworkflow_dispatchon this branch to confirm both images build green on CI (local Docker Desktop OOMs, so this is the authoritative check)🤖 Generated with Claude Code